运维思索：运维规范如何生成？

点击上方蓝色字体，关注我们

读完需 4 分钟

 速读需 2 分钟 

前面的文章老说“运维管理”、“运维自动化”，可能大家都听烦了，大道理谁都会说，能不能来点干货，把这些“大白话”落地？

我自己也不断在想是否应该将这些分享出来，因为都是自己在工作过程中的个人理解，都是野路子。但换个角度，运维的工作并不是简单的修修补补，而是给业务赋能，让自己实现价值的，因此接下来的文章更多的是进行落地。

运维框架

运维思考：运维管理与运维自动化一文中我们从运维工作中提取了运维框架（红色代表缺失），由基础设施层、数据层、应用层、管理层、展示层组成，生成了我们最终的运维体系。

下面我们从以下几个问题入手来深入探讨。

1

运维框架为什么要分层呢？

我认为有以下几点：

• 运维是面向团队而不是个人，分层能够让团队中每个人找到自己的工作的重点、明确运维的管理思路与目标。

• 分层其实是将运维工作进行了逻辑上的拆解，形成了上下文。因此我们做的某些操作并不是孤立的，会牵扯到不同的层次，是可以有生命周期的。
  例如：服务器上架，就涉及到以下几个层面：
  （1）基础设施层：服务器、操作系统等
  （2）应用层：基础组件、中间件等
  （3）管理层：无人值守、cmdb、监控等
  （4）展示层：zabbix、蓝鲸等
  在没有分层的情况下，我们就会孤立的重复操作，而忽略其实我们可以通过一套自动化流程彻底解决问题。

• 分层可以帮助我们更好的进行知识点梳理与盘点，对运维工作形成良性补充。

• 再说你就要说我吹NB了，但至少在我眼中是非常重要的，帮我理清了管理思路。

2

既然运维框架如此重要，那是如何生成的呢？

最终的运维框架其实并不是一蹴而就的，也是逐渐演化而来的，最初版如下：

最初版的运维框架粒度粗，但其核心要素为：

• 分为基础设施、系统应用、平台服务几个层次

• 基础组件、业务组件、公共组件

• 开发技术栈分类

无论运维框架如何演进，以上要素都会以不同形式存在，因此我们在此阶段需要好好梳理，为以后打好坚实的基础。

此阶段的缺点是系统应用服务偏离了，关联到业务上了，虽然运维是支撑业务的，但运维框架旨在梳理运维架构，为运维提供架构支撑。因此在后续单独分离应用层，从业务实现上分离出基础服务、业务应用、中间件三个共性特点。

运维规范

终于来到重点了，运维规范是如何生成的？

• 运维规范从来不是凭空捏造的，需要从碎片化的运维工作提取事实依据来生成

• 碎片化的运维工作存在于运维框架各个层面，因此运维规范按框架分层提取

明白以上两点后，我们就可以按照运维框架中的各个层次来提取了。当然由于运维框架的不断演进，因此运维规范是持续生成，不断补充到运维工作中。

1.基础设施服务

• 操作系统安装规范

• 目录管理规范

• 系统配置（初始化）规范

• JDK安装规范

• 网络设备配置规范

• 等等

2.系统应用规范

• 系统上线规范

• 进程管理规范

• 备份管理规范

• hosts规范

• 等等

3.平台服务规范

• 监控管理规范

• 系统巡检规范

• 日志收集规范

• 跳板机管理规范

• CI/CD规范

• 等等

规范生成如图：

规范最关键

当你有了规范后，是否应用了一段时间就不再更新了呢？

如果发生这种情况，我觉得主要是以下几个原因：

1. 规范的总结成了工作的负担；

2. 规范的风格不统一，团队不同成员因格式五花八门，非常混乱；

3. 规范的文字太多，阅读耗时，成了摆设；

另外，规范一定是可持续的，再结合以上问题，在最终生成规范时，运维团队需要明确规范的目的，使规范轻装上阵。

为解决这个问题，我给规范本身也定制了一个规范：

总结

运维规范只是自动化的前提，有了规范只是完成了万里长征的第一步，接下来我们只需要严格按规范去执行、不断的进行优化，剩下的都是水到渠成的事儿了。

最后，我的“野路子”就是这么来的，希望对大家有所启发，不喜勿喷！

关注我们